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Intellectual Property Rights 



IPRs essential or potentially essential to the present document may have been declared to ETSI. The information 
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found 
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in 
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web 
server ( http://webapp.etsi.org/IPR/home.asp) . 

Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee 
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web 
server) which are, or may be, or may become, essential to the present document. 



Foreword 

This Technical Specification (TS) has been produced by ETSI Technical Committee Telecommunications and Internet 
converged Services and Protocols for Advanced Networking (TISPAN). 

The architecture and functionality developed in the present document are in line with the capability requirements for 
hosted enterprise services developed in TS 181 019 [14]. 
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1 Scope 



The present document describes the architecture and functionaUty required to support enterprise and corporate services 
as IMS appHcations hosted in the NGN operator's network on behalf of an enterprise (Hosted Enterprise Services). 

The present document also specifies the protocol requirements for the UE to attach to the NGN (in particular the IMS) 
and also any protocol requirements related to application servers provided in support of hosted enterprise services. 



2 References 

References are either specific (identified by date of publication and/or edition number or version number) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• Non-specific reference may be made only to a complete document or a part thereof and only in the following 
cases: 

if it is accepted that it will be possible to use all future changes of the referenced document for the 
purposes of the referring document; 

for informative references. 

Referenced documents which are not found to be publicly available in the expected location might be found at 
http://docbox.etsi.org/Reference . 

For online referenced documents, information sufficient to identify and locate the source shall be provided. Preferably, 
the primary source of the referenced document should be cited, in order to ensure traceability. Furthermore, the 
reference should, as far as possible, remain valid for the expected life of the document. The reference shall include the 
method of access to the referenced document and the full network address, with the same punctuation and use of upper 
case and lower case letters. 

NOTE: While any hyperlinks included in this clause were valid at the time of publication ETSI cannot guarantee 
their long term validity. 

2.1 Normative references 

The following referenced documents are indispensable for the application of the present document. For dated 
references, only the edition cited applies. For non-specific references, the latest edition of the referenced document 
(including any amendments) applies. 

[1] ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Functional Architecture Release 1". 

[2] ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture". 

[3] ETSI TS 182 012: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS-based PSTN/ISDN Emulation Subsystem; Functional 
architecture". 

[4] ETSI ETS 300 738: "Human Factors (HF);Minimum Man-Machine Interface (MMI) to public 

network based supplementary services". 

[5] ETSI TS 123 228: "Digital cellular telecommunications system (Phase 2+); Universal Mobile 

Telecommunications System (UMTS); IP Multimedia Subsystem (IMS); Stage 2". 

[6] ETSI TS 182 009: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Architecture to support emergency communication from 
citizen to authority" . 
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[7] ETSI TS 187 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); NGN Security; Security Architecture". 

[8] ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description 
(3GPP TS 23.228 Release 7, modified)". 

[9] IETF RFC 3323: "A Privacy Mechanism for the Session Initiation Protocol (SIP)". 

[10] IETF RFC 3325: "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity 

within Trusted Networks". 

[11] ETSI TS 182 023: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Core and Enterprise NGN Interaction Scenarios and 
Architectural Requirements". 

[12] ETSI ES 282 002: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); PSTN/ISDN Emulation Subsystem (PES); Functional 
Architecture" . 

[13] ETSI ES 282 010: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Charging management [Endorsement of 3GPP TS 32.240 
Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 
3GPP TS 32.299 Release 7, modified]". 

[14] ETSI TS 181 019: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Business communication requirements". 

[15] ETSI ES 283 003: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IP Multimedia Call Control Protocol based on Session 
Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 
[Release 7] , modified] " . 

[16] ETSI TS 183 043: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); IMS based PSTN/ISDN Emulation Stage 3 specification". 

[17] ETSI TS 183 028: "Telecommunications and Internet converged Services and Protocols for 

Advanced Networking (TISPAN); Common Basic Communication procedures; Protocol 
specification" . 

[18] ETSI TS 124 229: "Digital cellular telecommunications system (Phase 2+);Universal Mobile 

Telecommunications System (UMTS);Internet Protocol (IP) multimedia call control protocol 
based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP);Stage 3 
(3GPP TS 24.229 version 8.2.0 Release 8)". 

[19] IETF RFC 503 1 : "A Uniform Resource Name (URN) for Emergency and Other Weil-Known 

Services". 

[20] ETSI TS 183 01 1: "Technical Specification Telecommunications and Internet converged Services 

and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Anonymous 
Communication Rejection (ACR) and Communication Barring (CB); Protocol specification". 

[2 1 ] IETF RFC 3966: "The tel URI for Telephone Numbers" . 

[22] IETF RFC 3261: "SIP: Session Initiation Protocol". 

[23] IETF RFC 4967: "Dial String Parameter for the Session Initiation Protocol Uniform Resource 

Identifier" . 

[24] draft-vanelburg-sipping-private-network-indication-02.txt: "The Session Initiation Protocol (SIP) 

P-Private-Network-Indication Private-Header (P-Header)". 
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2.2 



Informative references 



The following referenced documents are not essential to the use of the present document but they assist the user with 
regard to a particular subject area. For non-specific references, the latest version of the referenced document (including 
any amendments) applies. 

Not applicable. 



Definitions and abbreviations 



3.1 



Definitions 



For the purposes of the present document, the terms and definitions given in TS 181 019 [14], ES 283 003 [15] and 
TS 183 043 [16] apply: 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AGCF Access Gateway Control Function 

AGF Access Gateway Function 

AS Application Server 

BGCF Breakout Gateway Control Function 

BGF Border Gateway Function 

CNGCF Customer Network Gateway Configuration Function 

CS Circuit Switched 

CSCF Call Session Control Function 

HES Hosted Enterprise Services 

I-BGF Interconnection-Border Gateway Function 

I-CSCF Interrogating-Call Session Control Function 

IFC Initial filter Criteria 

IMS IP Multimedia Subsystem 

IN Intelligent Network 

IP Internet Protocol 

IPCAN IP Connectivity Access Network 

ISC IMS Service Control 

ISDN Integrated Services Digital Network 

LDAP Lightweight Directory Access Protocol 

MGCF Media Gateway Control Function 

MGF Media Gateway Function 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

NASS Network Attachment Subsystem 

NGCN Next Generation Corportate Network 

NGN Next Generation Network 

NGN Next Generation Network 

P-CSCF Proxy-Call Session Control Function 

PES PSTN/ISDN Emulation Subsystem 

PSTN PubHc Switched Telephony Network 

RACS Resource and Admission Control Subsystem 

RG Residential Gateway 

SCP Service Control Functio 

S-CSCF Serving-Call Session Control Function 

SGF Signalling Gateway Function 

SIP Session Initiation Protocol 

SLF Subscription Locator Function 

SPDF Service-based Policy Decision Function 

T-MGF Trunking-Media Gateway Function 
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UE 
UEE 
UPSF 
URI 

URN 
VGW 



User Equipment 
User Equipment Emulation 
User Profile Server Function 
Uniform Resource Identifier 
Uniform Resource Name 
Voice over IP Gateway 



Overview 



Hosted Enterprise Services (HES) refers to a solution where an NGN hosts all business communication capabilities to a 
set of endpoints connected to a plurality of access points to this network. This type of network solution is also known as 
IP Centrex. 

In the simplest configuration all endpoints are connected to a TISPAN NGN IP-CAN. Endpoints may be SIP phones or 
legacy phones (Analogue or ISDN) connected to a gateway. All services by HES are provided by application servers 
using standard IMS procedures. User may access services that are specific to the enterprise they belong to as well as 
services available to any other IMS users. 

In more complex configurations some of the endpoints may be connected to a 3GPP IPCAN and/or a circuit- switched 
network, which is itself connected to the IMS via an MGCF. Endpoints connected to heterogeneous access networks 
may be served by the same HES. 

Endpoints served by a HES shall have the ability to setup a session, identifying the communication target by: 

• a SIP URI of the form user ©domain; 

• an E. 164 telephone number; 

• a number within a private numbering plan; 

• local service numbers. 

With regard to supplementary services, HES have strong similarities with the provision of PSTN/ISDN simulation 
services, although the actual set of services may be different. Examples of services that are enabled by the architecture 
described in the present document are: 

All commonly used PSTN/ISDN services. 

IMS Multimedia Messaging, Presence and Conferencing services. 

Personal and Corporate Directory. 

Unified Voice mail. 

Operator assisted communications. 

Hot Line Calling. 

Abbreviate dialling. 

Line Hunting. 

Attended Communication Transfer. 

Blind Communication Transfer. 

Communication Pickup. 

Manager/Secretary filtering. 

CHck to Dial. 

Colour Ring Back Tone. 
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The sole purpose of the above Hst of services is to illustrate the type of services that are enabled by the architecture 
described in the present document. This list is not intended to be exhaustive nor is it expected that all implementations 
will support all of these services. The list actual of enterprise services hosted in a network is a matter for each operator 
to decide. 

NOTE: The present document provides a number of examples where domain names are used. It should be noted 
that these are for information only and are not intended to place any constraint on the structure and 
management of domain names as long as they are globally routable. 



Architecture 



5.1 



Functional Architecture 



5.1.1 Overview 

The functional architecture for supporting access to Hosted Enterprise Services is illustrated in figure 1 . This functional 
architecture supports access from both SIP based endpoints and legacy endpoints. 

The functional architecture for supporting access to Hosted Enterprise Services from both types of endpoints is obtained 
by a combination of the Core IMS Architecture defined in ES 282 007 [2] with the addition of an AGCF as defined in 
TS 182 012 [3] and ES 282 002 [12]. This should not be understood as an integration of an AGCF into the functional 
architecture defined in ES 282 007 [2]. The AGCF only applies to configurations where an H. 24 8 -controlled media 
gateway is required in support of legacy endpoints. 
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Figure 1 : Functional architecture overview 

All functional entities behave as defined in ES 282 007 [2], TS 182 012 [3] and/or ES 282 002 [12]. 

The service logic of the HES resides in one or more application servers. All sessions to/from a member of a HES shall 
be handled by at least one application server. 

SIP-based endpoints may be connected to the IMS via any IF'CAN valid for the current specification release. A HES 
may serve endpoints connected through both types of IP-CANs. 
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Legacy endpoints may be connected via a media gateway or a SIP-based Voice over IP Gateway (VGW). Both types of 
gateways may be part of the User Equipment (UE) or reside in the TISPAN IP-CAN. A SIP-based Voice over IP 
Gateway (VGW) plays the role of a UE with regards to the P-CSCF. A media gateway is controlled by the AGCF, 
which plays the combined role of a UE and a P-CSCF with regards to other CSCFs of the IMS. 

TS 182 012 [3] provides a more detailed specification of the procedures that a VGW and AGCF shall support for 
enabling access to IMS -supported services from legacy endpoints. 

NOTE: The concepts of "Media Gateway" and AGCF are defined in both TS 182 012 [3] and ES 282 002 [12]. A 
Media Gateway implements the R-MGF or A-MGF functional entities defined in ES 282 001 [1]. 
ES 282 002 [12] uses different names to refer to a Media Gateway depending on its location: a media 
gateway located in the customer premises is referred to as a Residential Gateway (RG) while a media 
gateway located in the IP-CAN is referred to as an Analogue Gateway Function (AGE). 

5.1 .2 Involved functional entities - originating session 

Figure 2 shows the functional entities involved in an originating session. 
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Figure 2: Functional entities involved in originating sessions 

NOTE: Figure 2 does not show the intermediate functions between the P-CSCF and the S-CSCF, or those 
between the S-CSCF and the terminating side. 

The originating side can interoperate with any other terminating side scenario. 
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5.1 .3 Involved functional entities - terminating session 

Figure 3 shows the functional entities involved in a terminating session. 



Charging 
Functions 



AS 

(HES logic) 



From originating side 




Mp 



Gq', e2, P1 



Core Transport 



Gq-Rx 



Gq', e2 



Gm 



3GPP IP 
CAN 



TISPAN 
IP-CAN 



UE 



Figure 3: Functional entities involved in terminating sessions 

NOTE: Figure 3 does not show the intermediate functions between the P-CSCF and the S-CSCF, or those 
between the S-CSCF and the originating side. 

The terminating side can interoperate with any other originating side scenario. 

5.2 Architecture involving heterogeneous core networks 

A HES can serve a set of endpoints some of which being connected to the IMS and some others being connected to 
Circuit- Switched (CS) networks. Example scenarios are shown in annex B. 



Procedures 



6.1 Registration 

Registration procedures comply with TS 182 006 [8] or TS 182 012 [3] depending on the type of endpoint. 

NOTE: Registration procedures for endpoints not connected directly to a 3 GPP or TISPAN IP CAN are outside 
the scope of the present document. 

The IMS public user identity used at registration is in the form of a SIP URL This SIP URI can include a user name in 
the form of a telephone number with a user=phone parameter where the telephone number is either a public e.l64 or a 
private number; if private numbers are used, the private numbering plan shall be uniquely identifiable by the NGN. 
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6.2 Originating session procedures 

Originating communication setup procedures shall comply with TS 182 006 [8] or TS 182 012 [3] depending on the 
type of endpoint. 

In addition to the procedures specified in this clause, the UE shall comply with the requirements identified in 
TS 124 229 [20], clause 4.1 as modified by ES 283 003 [15]. 

In addition to the procedures specified in the following clauses, the AGCF shall comply with the procedures specified in 
TS 183 043 [16] appropriate to this entity. 

In addition to the procedures specified in the following clauses, each IMS functional entity shall comply with the 
procedures specified in the clauses of ES 283 003 [15] and TS 183 028 [17] appropriate to this entity. 

An AS providing the logic of an originating HES may provide communication admission control in terms of number of 
simultaneous communications to/from this particular HES. 

Support of private numbering is described in clause 6.5. 

Certain services require that the UE or an AGCF can be configured to insert a default session destination in the Request 
URI when a dialstring is not entered by the end user. In the case of the UE, the default session destination may be 
manually configured by the user or received from the CNGCF. This configured default session destination can either 
point to the terminating end point for the session or a value independent from the actual destination. In the latter case, 
the AS acting as the originating HES determines the actual session destination from local configuration data and/or the 
user profile and rewrites the Request URI. 

The AS procedures for modification of the P-Asserted-Identity headers fields for originating requests typically depend 
on: 

• operator and enterprise domain policies; 

• privacy settings as specified in RFC 3323 [9] and RFC 3325 [10]; 

• whether the destination belongs to the same enterprise domain than the session initiator, 
with the following restrictions: 

• when the terminating endpoint is outside the HES's domain (i.e. public domain or business trunking services 
see note) and no privacy restrictions apply, the identity in the P-Asserted-Identity representing the HES user 
shall be a globally routable SIP or tel URI. 

NOTE: The originating side hosted enterprise services scenario can interoperate with any other terminating 
scenario. 

As an example, an AS providing the logic of an originating HES, based on enterprise policies, can perform the 
following changes with regards to the identities it receives in INVITE messages: 

• override the P-Asserted-Identity to an identity derived from the received value. This identity is in the form of a 
telephone number representing for example an attendant or in the form of a URI of type user ©domain, where 
the user part represents the HES or a partition of this HES (e.g. site-based partitions) and the domain part 
represents the enterprise; 

• override the URI part of the From header field with the value received in the P-Asserted-Id header field, with 
the exception that an anonymous value in the From header field must not be modified. 

Depending on the type of changes made, the AS will act as a SIP Proxy as defined in TS 124 229 [20], clause 5.7.4 as 
endorsed by ES 283 003 [15], as a Routing B2BUA or an Initiating B2BUA, as defined in TS 124 229 [20], clause 5.7.5 
as endorsed by ES 283 003 [15]. 
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6.3 Terminating session procedures 

Terminating communication setup procedures shall comply with TS 182 006 [8] or TS 182 012 [3] depending on the 
type of endpoint. 

In addition to the procedures specified in this clause, the UE shall comply with the requirements identified in 
TS 124.229 [20], clause 4.1 as modified by ES 283 003 [15]. 

In addition to the procedures specified in the following clauses, the AGCF shall comply with the procedures specified in 
TS 183 043 [16] appropriate to this entity. 

In addition to the procedures specified in the following clauses, each IMS functional entity shall comply with the 
procedures specified in the clauses of ES 283 003 [15] and TS 183 028 [17] appropriate to this entity. An AS providing 
the logic of an terminating HES may provide communication admission control in terms of number of simultaneous 
communications sent to/from this particular HES. 

Terminating communications to a group is described in clause 6.6. 

6.4 Emergency communications 

The AGCF procedures for emergency communication are specified in TS 183 043 [16]. 

Processing of emergency communications by other network entities shall conform to TS 182 009 [6], except where the 
enterprise requires a special arrangement whereby emergency communications are delivered to a destination within the 
enterprise (hosted or supported by an NGCN). Such an arrangement may also involve enterprise specific emergency 
numbers. 

NOTE: Procedures for supporting the above special arrangement are outside the scope of the present document. 

6.5 Capabilities provided to an enterprise 
6.5.1 General 

Hosted enterprise services (HES) are deployed on one or more applications servers. HES may provide enterprise level 
capabilities. When such capabilities are offered to a specific enterprise the initial filter criteria of the service profile of a 
connected HES user needs to be configured so that the S-CSCF that serves the HES user invokes the AS that hosts the 
HES. 

The intent of this clause is not to specify the detail of the individual services, but only to indicate some specific impacts 
on the protocol. 

TS181019[14] defines the enterprise capabilities that HES shall support, this clause specifies protocol impact of the 
different applications. 
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6.5.2 Routeing capabilities 

6.5.2.1 Overview 

6.5.2.2 Break-in 

No specific protocol action is required for a HES providing break-in. 

6.5.2.3 Break-out 

When break-out is enabled for a specific enterprise, a HES converts incoming private network traffic to public network 
traffic if the conditions agreed between the enterprise and the NGN operator indicate this. 

To convert private network traffic to public network traffic the break-out service shall remove 

Private-Network-Indicator header field if present as specified in [24], from the initial request for a dialog or standalone 
request for a transaction. 

To allow this service to be provided it needs to be ensured that the HES logic offering this service will be inserted in the 
signalling path of sessions originating from and terminating to the served HES user. 

6.5.3 Communication admission control 

When communication admission control is enabled a HES serving an enterprise executes the NGN operator defined set 
of rules or policies under which communication admission control applies, and the enterprise should be able to 
configure the capability within those rules and policies. 

To allow this service to be provided it needs to be ensured that the HES logic offering this service will be inserted in the 
signalling path of sessions originating from and terminating to the served HES user. 

6.5.4 Anonymous communication rejection 

When anonymous communication rejection is enabled a terminating HES serving a HES user providing this service 
shall implement the procedure as specified in TS 183 Oil [20], clause 4.5.2.6.2. 

To allow this service to be provided it needs to be ensured that the HES logic offering this service will be inserted in the 
signalling path of sessions terminating to the served HES user. 

6.6 Private Numbering 
6.6.1 General 

Sessions from endpoints served by a HES can be established using private numbering to any type of destination, 
including the PSTN, another endpoint served by the same or different HES, an endpoint served by an NGCN belonging 
to the same or a different enterprise as well as any other IMS user. 

The following clauses provide further details on the handling of private numbering by the UE and the network. 

NOTE: In case of legacy endpoints the UE procedures required in support of private numbering are performed by 
the functional entity providing the UE role with regards to the IMS (i.e. AGCF or VGW). 
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6.6.2 UE behaviour 

6.6.2.1 General 

Private numbering information is sent in the Request-URI of the originating SIP requests, using one of the following 
formats: 

1) A TEL URI, complying with RFC 3966 [21], with a local number followed by a phone-context value. 

2) A SIP URI, complying with RFC 3261 [22], with the user =phone parameter. 

3) A SIP URI, complying with RFC 3261 [22] and RFC 4967 [23], with the user=dialstring parameter. 

NOTE: A UE can use a SIP URI complying with RFC 3261 [22], where the user part contains a string of digits 
corresponding to a private number and the domain name is specific enough to enable the network to 
understand that the user part contains private numbering information and the context in which it has to be 
interpreted. 

The actual value of the URI depends on whether the user equipment performs an analysis of the dial string input by the 
end user. 

6.6.2.2 UE without dial string processing capabilities 

In this case the UE does not perform any analysis of the dial string. This requires that the dialling plan be designed so as 
to enable the AS acting as an originating HES to differentiate private numbers from other numbers. 

The dial string may be sent to the network, in the Request URI of SIP requests, using one of the following formats: 

1) A TEL URI, syntactically complying with RFC 3966 [21], with the dial string encoded as a local number 
followed by a pre-configured fixed phone-context value. 

EXAMPLE: tel:<input dial string>;phone-context=unproces seddialstring.example.com. 

2) A SIP URI, syntactically complying with RFC 3261 [22], with the user =phone parameter, embedding a 
TEL-URI with a pre-configured fixed phone-context value. 

EXAMPLE : sip : <input dial string> ; 

phone-context=unprocesseddialstringexample.com@operator.com;user=phone. 

3) A SIP URI, complying with RFC 3261 [22] and RFC 4967 [23], with the user=dialstring parameter and a with 
a pre-configured fixed phone-context value in the user part. 

EXAMPLE : sip : <input dial string> ; 

phone-context=unprocesseddialstringexample.com@operator.com;user=dialstring. 

4) A SIP URI syntactically complying with RFC 3261 [22], where the user part contains the dial string and the 
domain name is specific enough to enable to network to understand that the user part contains a dial string. 

EXAMPLE: sip:<input dial string>@ dialstrings.entreprise.com. 

6.6.2.3 UE with dial string processing capabilities 

In this case the UE performs sufficient dial string analysis (or receives an explicit indication from the user) to identify 
whether private numbering is used and processes the dial string accordingly before building the Request-URI. 

If the UE detects that a public dialling plan or a private dialling plan is being used, where the terminal is able to identify 
a global telephone number, the procedures described in ES 283 003 [15] apply after removing all dial string elements 
used for public numbering detection purposes (e.g. escape codes). 

If the UE detects that a private dialling plan is being used, it may decide to send the dial string unchanged to the 
network or to alter it to comply with the private numbering plan (e.g. remove all dial string elements used for private 
numbering detection). 
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Annex A provides examples of UE processing options and of population rules for the Request-URI fields and 
parameters. As a general rule, recognition of special service numbers takes priority over other dialling plan issues. If the 
dial string equates to a pre-configured service URN (see RFC 5031 [19]) then the service URN should be sent. 

6.6.3 Network behaviour 

The use of numbers in PNPs and in user specific dial plans shall be provided in the following manner: 

1) The P-CSCF or AGCF routes the session towards the S-CSCF as per the session origination procedures. 

Processing the Request URI (e.g. address analysis and potential modification such as translation into globally 
routable format) shall be performed by an AS providing the logic of an originating HES in the user's Home 
Network. The S-CSCF routes the SIP request towards this AS based upon filter criteria. 

The translation procedure relies on data stored in the AS or in an external database, separated from the AS 
using e.g. a LDAP interface. If user-specific dialling plans are supported, translation data may also be stored in 
the UPSF, in which case the AS accesses this data using the Sh reference point. 

2) This AS passes the session request back to the S-CSCF with a Request URI that contains either a globally 
routable SIP URI or a Tel URI with a number in international format. The SIP request shall contain enough 
information to route to the terminating network and allow the terminating network to identify the intended end 
point. 

3) After processing the Request URI the S-CSCF shall route the SIP request, via normal IMS routing principles, 
towards its destination. 



6.7 Group Management 



One or more IMS groups (as defined in TS 123 228 [5]) may be associated with one or more HESs. Each group shall be 
addressable by a globally unique group identifier. The group identifier shall take the form of a Public Service Identifier. 

6.8 Supplementary service control 

It shall be possible to configure all services (e.g. communication forwarding conditions, selective communication 
filtering criteria, etc.) using the Ut reference point, a Web portal or using service code commands. 

Users shall be able to control supplementary services using service code commands sent in session initiation requests. 
One possible syntax for such commands is defined in ETS 300 738 [4], in which case the actual values used in the 
different fields of the commands may differ from those specified in this ETS [4] ( and service code commands 
(excluding the START and FINISH fields) shall be encoded as a local-number using and appropriate "phone-context" 
value. 



Use of Transport Functions 



7.1 UseofRACS 

Use the RACS functions conforms to ES 282 007 [2], TS 182 012 [3] and/or ES 282 002 [12]. 

7.2 Use of NASS 

Use the NASS functions conforms to ES 282 007 [2], TS 182 012 [3] and/or ES 282 002 [12]. 

7.3 Use of transport processing functions 

Support of HES does no place any specific requirement on transport processing functions. 
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8 Security issues 

The security requirements for the support of HES are specified in TS 187 003 [7]. 

9 IVIanagement Issues 

9.1 Configuration/provisioning issues 

9.1.1 UPSF 

Appropriate Initiate Filter Criteria have to be configured in the UPSF for each of the pubHc user identities associated to 
HES usage. Within a user profile, one of the IFCs shall lead to the AS providing the HES logic for the user. 

Shared IFCs may be used to ease provisioning and minimize the amount of signalling information over the Cx reference 
point. 

9.1.2 User Equipment 

SIP-based User Equipment can be configured with the following pieces of information: 

• Rules the UE must apply to dialled numbers in order to detect the use of private numbering plans and 
determine which private numbering plan is being used. 

NOTE: It is expected that these rules do not require a complete number to be available to derive a private 
numbering plane. 

• Phone-context identifiers or domain names associated to each numbering plan supported inside their HES 
domain. 

9.1.3 AGCF 

The AGCF shall be configured with the same pieces of information than a SIP-based User Equipment. 

9.1.4 Charging issues 

The charging architecture and functions defined in ES 282 010 [13] are applicable. 

Charging Information on operator-assisted communications shall be collected and recorded for the public user identity 
of the actual calling user rather than the public user identity of the operator, even though this operator may be connected 
to the network as a normal user. The collected information shall enable creating a consolidated charging record 
including the information related to the segment between the user and the operator and between the operator and the 
destination. 

Charging records shall keep track of the services invoked during each communication. 
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Charging records shall contain sufficient information to enable generating consolidated reports based on: 
the distribution of communications during a day, a week, a month or a year; 
the distribution between internal and external communications; 
the number of incoming/outgoing communications; 
the number of nationals/internationals sessions; 
the number of forwarded communications per forwarding condition; 
the use of voice mail and conferencing services; 
the number of successful/unsuccessful communications. 
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Annex A (informative): 

Processing of dial strings by the UE 

Processing of a dial string by a UE depends on whether one or more private numbering plans are supported. 

A.1 Single private numbering plan 

If the UE detects that a private dialling plan is being used, it may decide to send the dial string unchanged to the 
network or to alter it to comply with the private numbering plan (e.g. remove all dial string elements used for private 
numbering detection). The resulting dial string may be sent, in the Request URI of SIP requests, using one of the 
following formats: 

1) A TEL URI, complying with RFC 3966 [21], with local number and a pre-configured fixed phone-context 
value. 

tel:<output dial string>;phone-context=pnp. entreprise.com. 

2) A SIP URI, complying with RFC 3261 [22], with the user =phone parameter. 

sip :<output dial string>;phone-context=pnp.entreprise.com@operator.com;user=phone. 

3) A SIP URI, complying with RFC 3261 [22] and RFC 4967 [23], with the user =dialstring parameter (see note). 

sip :<output dial string>;phone-context=pnp.entreprise.com@operator.com;user=dialstring. 
NOTE: This option only applies if the dial string was not completely processed into a private number string. 

4) A SIP URI complying with RFC 3261 [22], where the user part contains the dialled string (possibly modified) 
and the domain name is specific enough to enable to network to understand that the user part contains a 
dialstring according to a private numbering plan or private dialling plan. 

sip:<output dialstring> @ pnp.entreprise.com. 

In the first three cases, the phone-context value indicates that a private number is being used that belongs to the single 
private numbering plan. 

A.2 Multiple private numbering plans 

If the end user is entitled to use more than one private numbering plan, the UE will either proceed as above, providing 
that the remaining dial string contains sufficient information for the network to identify the private numbering plan 
being used, or determine the private numbering plan being used and send the dial string in the Request URI of SIP 
requests, using one of the following formats: 

1) A TEL URI, complying with RFC 3966 [21], with local number and a pre-configured phone-context value 
corresponding to the private numbering plan used. 

tel:<output dial string>;phone-context=pnp-value.entreprise.com. 

2) A SIP URI, complying with RFC 3261 [22], with the user =phone parameter. 

sip :<output dial string>;phone-context=pnp-value.entreprise.com@operator.com;user=phone. 

3) A SIP URI, complying with RFC 3261 [22] and RFC 4967 [23], with the user =dialstring parameter (see note). 

sip :<output dial string>;phone-context=pnp-value.entreprise.com@operator.com;user=dialstring. 
NOTE: This option only applies if the dial string was not completely processed into a private number string. 
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4) A SIP URI complying with RFC 3261 [22], where the user part contains the dialled string (possibly modified) 
and the domain name is specific enough to enable to network to understand that the user part contains a dial 
string according to a particular private numbering plan or private dialling plan. 

sip:<output dialstring> @pnp-value. entreprise.com. 

In the first three cases, the phone-context value indicates the private numbering plan the dial string belongs to. 
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Annex B (informative): 

Scenarios for HES extension to CS users 

Figure B.l provides an overview of a functional architecture that can support a number of deployment scenarios for 
extending HES to CS endpoints. Functions within the dotted box in figure B.l represent functions that may physically 
reside in one or more IMS application servers. For a given deployment scenario not all of the functions may be needed 
however to provide HES to a CS endpoint at least one AS will contain HES logic. 

NOTE: A multimode UE is included in the set of endpoints a HES can serve. An example of a multimode UE is 
one that can assume the UE role and the Legacy Endpoint role (see figure B.l). Simultaneous 
connectivity to IP-CAN and CS is subject to the constraints of the access network and the UE. 
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Figure B.1 : Functional Arcliitecture for supporting hybrid accesses 
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The functional architecture shown in figure B.l allows the following deployment scenarios: 

• Scenario 1 (SI): In this scenario IN triggers in the CS network route the call to an IN SCF interacts with the 
HES logic. The IN SCF controls the call in the CS network as per the HES logic. For this approach both the IN 
SCF and HES logic are co-located in the same IMS AS. 

• Scenario 2 (S2): In this scenario IN triggers in the CS network route the call to an IN SCF which has access to 
HES routing data. The IN SCF redirects the call to the IMS. HES are applied to the session using the ISC 
reference point to access the IMS logic which in turn accesses the HES logic. 

• Scenario 3 (S3): In this scenario the CS network routes calls from CS users to the IMS. The mechanism by 
which this re-routing is achieved is out of scope of the present document. Upon entering the IMS PSI routing 
is used to route the call to the IMS User Equipment Emulation (UEE). The UEE is used to anchor the call in 
the IMS. The UEE uses IMS logic to initiate a session into the IMS on behalf of the CS endpoint. To apply 
HES the filter criteria for this pseudo user will include the HES. HES are invoked using the ISC reference 
point to access the IMS logic which in turn accesses the HES logic. For calls to the CS user, the UEE will be 
configured in the terminating filter criteria to be the last application in the chain. 
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